home *** CD-ROM | disk | FTP | other *** search
/ PsL Monthly 1993 December / PSL Monthly Shareware CD-ROM (December 1993).iso / prgmming / dos / basic / smalle.com / SMALLEXE.TXT < prev   
Encoding:
Text File  |  1990-12-16  |  9.8 KB  |  218 lines
  1.  
  2.  This text file explains how to create smaller standalone QuickBASIC
  3.  executables. Hopefully it will help others avoid some of the frustration
  4.  I encountered learning HOW to accomplish this! Two topics are discussed:
  5.  
  6.    1. How to eliminate floating point emulation code, and
  7.    2. Other tricks and tips
  8.  
  9.  I am the author of pEDIT, a shareware text editor written in QB 4.5. As
  10.  pEDIT grew larger and larger, it became necessary for me to look at ways
  11.  of reducing the size of the program. I considered 5 options:
  12.  
  13.    1. Stick with QB and do - something
  14.    2. Go to BASIC7 which is supposed to generate smaller/faster code
  15.    3. Go to something like Crescent's PDQ which uses an alternate link
  16.        library to generate smaller EXEs
  17.    4. Wait for QB 5.0 or QBX or ??? from Microsoft
  18.    5. Rewrite pEDIT in 'C'
  19.  
  20.  QB is a great product for the price but it is NOT known for generating
  21.  small programs! The smallest EXE under QB4.5 is something like 12-15k
  22.  bytes. This is due mainly to the HUGE amounts of object code linked in
  23.  after compiling. It turns out that Microsoft's BCOM libraries are not
  24.  (here's a 25-cent word) granular enough. This means that whenever you
  25.  link in a procedure you are probably getting the code for several other
  26.  procedures. Sometimes the added code is insignificant; sometimes it is
  27.  HUGE.
  28.  
  29.  An example is the HEX$() function. Whenever you use HEX$() you are
  30.  linking in a library module named 'hexoct' which contains three entry
  31.  points: B$FBIN (there is no BIN$() function), B$FHEX (what you want) and
  32.  B$FOCT (for the OCT$() function). The 'hexoct' module is only 50H bytes
  33.  but you get the idea. Why have code for octal when you're doing hex?
  34.  
  35.  I could not justify $300+ for BASIC7, especially not knowing how much
  36.  improvement I could expect. Besides, I don't have an extra 10MB of disk,
  37.  a need for ISAM, etc.
  38.  
  39.  PDQ is useful mainly for things like small utilities. It does generate
  40.  very small executables (as little as 1-2k) but it is just TOO DIFFERENT
  41.  from QB to be useful for large programs. MANY standard (read as Micro-
  42.  soft) BASIC functions are not supported, requiring massive changes.
  43.  
  44.  Who knows when/if there will be a new QB with an optimizing compiler,
  45.  better link library, etc. I hope there will be something like the QBX
  46.  included with BASIC7. I have a major upgrade planned for pEDIT in January
  47.  1991 and can't wait.
  48.  
  49.  I hate 'C'.
  50.  
  51.  
  52.                                 FLOATING POINT
  53.                                 --------------
  54.  
  55.  There isn't much we can do about the granularity problem. We have no
  56.  control over what Microsoft puts in their link libraries or how many
  57.  different procedures there are in each module. We can do something about
  58.  eliminating unnecessary floating point code. This turned out to be easier
  59.  said than done(!) Things you wouldn't DREAM use floating point - do.
  60.  
  61.  To see if your program contains the floating point code, generate a link
  62.  map and look for EMULATOR_TEXT and EMULATOR_CODE. In BCOM45 these modules
  63.  are 2430H and 0170H bytes, respectively. If this floating point support
  64.  is present and you don't need it, you're adding an incredible 9632 bytes
  65.  of code to your program.
  66.  
  67.  Following is a list of BASIC functions/keywords with information on
  68.  each's use of floating point. Obviously you can't have any real variables
  69.  declared - VAR! or VAR#. Also just as obviously, you can't use any real
  70.  operators or any function which is explicitly for floating point - INT(),
  71.  FIX().
  72.  
  73.      What               What to do 
  74.      --------------    ---------------------------------------------------
  75.      
  76.      / (division)    Replace by \ (integer division); instead of PCT# =
  77.                  100 * (A/B) use PCT& = (100& * A) \ B
  78.      
  79.      TIMER        Returns seconds since midnight (~18.2 ticks per sec-
  80.              ond); replace by a FUNCTION that reads the system
  81.              clock and returns ticks; see sample ReadTimer&()
  82.      
  83.      INPUT        Can input reals so must replace by a BASIC SUB or
  84.              FUNCTION that uses e.g. INKEY$
  85.      
  86.      INPUT #        Same as above; see LINE INPUT #
  87.      
  88.      VAL()        One of the biggest offenders, always uses emulation;
  89.                  it is also quite large and slow; use a replacement
  90.                  such as NuVal&() - available on this Forum - or my
  91.                  FUNCTION StrToInt&()
  92.      
  93.      ABS()        Uses emulation only if the argument is a real
  94.      
  95.      STR$()        Uses emulation only if the argument is a real;
  96.             CAREFUL: the may be cases when the compiler can't
  97.             tell there won't be any floating point?; if so,
  98.             need IntToStr$(), the reverse of StrToInt&()
  99.      
  100.      PRINT USING    Uses emulation only if the print mask is for a real
  101.              number, e.g. "###.##"
  102.      
  103.      READ        Expected because you can READ into a real variable;
  104.                  however you might think QB would be smart enough to
  105.                  scan the DATA and see if any is float? replace by a
  106.                  DATA$ string and a FUNCTION to parse it; see sample
  107.                  ReadData$()
  108.  
  109.      LINE INPUT #    Makes no sense at all as can *ONLY* input a string!
  110.                  must replace by some other method of INPUTing a
  111.                  single line at a time; note that INPUT # and LINE
  112.                  INPUT # are very slow in reading sequential ASCII
  113.                  data; see sample SUB InputLine()
  114.  
  115.  The archive contains the sample programs SMALLEXE.BAS and LARGEEXE.BAS.
  116.  SMALLEXE.BAS uses the mentioned InputLine(), ReadData$(), ReadTimer& and
  117.  StrToInt&() replacements for LINE INPUT #, DATA/READ, TIMER and VAL().
  118.  When compiled under QB 4.5 and linked with NOCOM+SMALLERR (see below),
  119.  the EXE sizes are 21088 and 33308 bytes, respectively.
  120.  
  121.  I was able to reduce the size of PEDIT.EXE by 11,200 bytes. While this is
  122.  not a huge reduction every bit helps. It would be difficult to trim this
  123.  much by tweaking!
  124.  
  125.  
  126.  
  127.                              OTHER TIPS AND TRICKS
  128.                              ---------------------
  129.  
  130.  Other things can be done to reduce the EXE size. One easy way - which I
  131.  just rediscovered - is to link with NOCOM.OBJ. This object file is pro-
  132.  vided by Microsoft but was not included with QB 4.5. I found it mentioned
  133.  in the file BASAPP.TXT in this Forum. You can get NOCOM from Microsoft or
  134.  use the one included with previous versions of QB. Microsoft claims a
  135.  reduction of ~4k bytes; I saw about 3k. Note: NOCOM can be used only if
  136.  you program uses no serial communications.
  137.  
  138.  Next, link with SMALLERR.OBJ (also from MS). This saves a few bytes by
  139.  eliminating the text of error messages; you will get an error number
  140.  only. You might want to do this after your program is debugged.
  141.  
  142.  Minimize string usage. All assigned strings (as in VAR$ = "HELLO") have
  143.  to be stored somewhere. QB limits string space to a total of 64k so it is
  144.  easy to run out... the infamous "Out of string space" message. If pos-
  145.  sible, 'deassign' string variables to "" when you're done with them.
  146.  
  147.  Eliminate the INTOLD86(X) routines in Microsoft's QB.BI. These are for
  148.  the old interrupt calls INT86() and INT86X(). The object code is in both
  149.  QB.QLB and QB.LIB. It turns out EVERYTHING in QB.LIB is included at link
  150.  time; you can again see it in the link map. If you don't need these old
  151.  INT86 routines, build new QB.QLB and QB.LIB files with just support for
  152.  CALL ABSOLUTE and CALL INTERRUPT(X). Following is a sample BAT file to do
  153.  this with QB 4.5:
  154.  
  155.      rem
  156.      rem Extract existing modules from QB LIBrary
  157.      rem
  158.      lib qb.lib *absolute *intrpt ;
  159.      rem
  160.      rem Build the new QuickLibrary w/o int86old
  161.      rem
  162.      link /quick absolute+intrpt,qb.qlb,,bqlb45 ;
  163.      rem
  164.      rem Build new LIBrary
  165.      rem
  166.      lib qb.lib absolute+intrpt ;
  167.      rem
  168.      del absolute.obj
  169.      del intrpt.obj
  170.  
  171.  
  172.          ----------------end-of-author's-documentation---------------
  173.  
  174.                          Software Library Information:
  175.  
  176.                     This disk copy provided as a service of
  177.  
  178.                            Public (software) Library
  179.  
  180.          We are not the authors of this program, nor are we associated
  181.          with the author in any way other than as a distributor of the
  182.          program in accordance with the author's terms of distribution.
  183.  
  184.          Please direct shareware payments and specific questions about
  185.          this program to the author of the program, whose name appears
  186.          elsewhere in  this documentation. If you have trouble getting
  187.          in touch with the author,  we will do whatever we can to help
  188.          you with your questions. All programs have been tested and do
  189.          run.  To report problems,  please use the form that is in the
  190.          file PROBLEM.DOC on many of our disks or in other written for-
  191.          mat with screen printouts, if possible.  PsL cannot debug pro-
  192.          programs over the telephone, though we can answer questions.
  193.  
  194.          Disks in the PsL are updated  monthly,  so if you did not get
  195.          this disk directly from the PsL, you should be aware that the
  196.          files in this set may no longer be the current versions. Also,
  197.          if you got this disk from another vendor and are having prob-
  198.          lems,  be aware that  some files may have become corrupted or
  199.          lost by that vendor. Get a current, working disk from PsL.
  200.  
  201.          For a copy of the latest monthly software library newsletter
  202.          and a list of the 2,000+ disks in the library, call or write
  203.  
  204.                            Public (software) Library
  205.                                P.O.Box 35705 - F
  206.                             Houston, TX 77235-5705
  207.  
  208.                                 1-800-2424-PSL
  209.                              MC/Visa/AmEx/Discover
  210.  
  211.                           Outside of U.S. or in Texas
  212.                           or for general information,
  213.                               Call 1-713-524-6394
  214.  
  215.                           PsL also has an outstanding
  216.                           catalog for the Macintosh.
  217.  
  218.